Content providers often stream data, such as audio, video, and/or other content from one or more servers to requesting clients via a content distribution network (CDN). As an example, music or movies may be delivered to desktops of distributed users with low delay and free interactivity (supporting, for example, pause, jump, fast-forward, rewind, etc.). “Streaming media” as used herein refers to any type of data (e.g., audio, video, and/or other types of content) that is communicated to a recipient in a streaming fashion such that the recipient may begin playback of the streaming data before all of the streaming data is received by the recipient (i.e., the recipient may playback a received portion of the streaming data while portions of the streaming data to be played in the future continue to be received by the recipient). Streaming media is a well-known technology in the computer arts. In general, streaming media presents data (e.g., typically audio and/or video) to a client in a streaming or continuous fashion. That is, with streaming media a client is not required to receive all of the information to be presented before the presentation begins. Rather, playback of content in a streaming media file may begin before all of the file is received by the client, and as the received portion of the file is being played back, further portions of the file continue to be received by the client for later playback.
Various streaming media players are well-known in the art. Popular streaming media players include those provided by RealNetworks™ (see http://www.realnetworks.com), such as its RealPlayer™ and RealOnePlayer™ streaming media players, and that used by Microsoft's Windows® Media Player (see http://www.microsoft.com), as examples. Typically, each streaming media player has a buffer associated therewith for buffering received streamed data to improve the continuity of the playback of such streamed data by the streaming media player (e.g., in order to maintain a substantially smooth playback of the streaming data).
A traditional client-server model, where a dedicated stream is established between each requesting client and the server, has limited scalability due mainly to heavy server load and limited network bandwidth at the server side. More recently, peer-to-peer (P2P) networks have been increasing in popularity for many scalable applications, such as streaming and file sharing among users over the world. In P2P systems, cooperative peers self-organize themselves into overlay networks, typically via unicast tunnels. Each peer may be a personal computer (PC), laptop computer, personal data assistant (PDA), mobile telephone, or other processor-based computing device that is communicatively coupled to the P2P network. Each peer (sometimes called an overlay node in an overlay network) acts as an application-layer proxy, caching and relaying data for other peers. In addition, by sharing their own resources, such as storage and network bandwidth, the capacity of the whole system is vastly amplified compared to traditional client-server architecture. Thus, end-systems (e.g., clients) often form a P2P network, wherein the end-systems, acting as peers, may share data with each other. For instance, an end-system acting as a peer may contribute its bandwidth and storage to aid in the distribution of content among the peers.
Various P2P technologies have been proposed. As one example, U.S. Patent Application Publication No. 2008/0155120 A1 titled “METHOD AND SYSTEM FOR PEER-TO-PEER CONTENT DISSEMINATION” (hereinafter “the '120 Publication”) proposes use of a P2P network for content dissemination among peers. According to the '120 Publication, a sender decides how much data to send according to the number of bytes it has received from the requester (see e.g., paragraphs 0050-0055 of the '120 Publication). The goal of the '120 Publication is to prevent malicious attack or a selfish peer in the P2P network. However, the '120 Publication does not address live streaming content, and its proposed solution does not appear to be suitable for live streaming content due, for instance, to its relatively long response time.
As another example, U.S. Patent Application Publication No. 2008/0140853 A1 titled “PEER-TO-PEER STREAMING OF NON-LIVE CONTENT” (hereinafter “the '853 Publication”) proposes another use of a P2P network for streaming of non-live content. The '853 Publication's method is based on BitTorrent, a known scheduling algorithm that relies on a rarest-first strategy. The '853 Publication does not address live streaming content, and its proposed solution employing the BitTorrent scheduling algorithm does not appear to be suitable for live streaming content due, for instance, to its lack of time-sensitivity regarding the data being requested.
As still a further example, U.S. Patent Application Publication No. 2008/0037527 A1 titled “Peer-to-Peer Interactive Media-on-Demand” (hereinafter “the '527 Publication”) proposes a method for media-on-demand (MoD) communications in a P2P network. The '527 Publication proposes structuring and storing registration information including media information, play start time and locality of registering peer node. Then, upon receiving a request, a determination is made of a list of parent nodes that can optimally provide media downloading service to requesting peer in dependence of media information requested, its media play start time and locality information of requesting peer. Then, the requesting peer is connected to at least one of the parents to receive, buffer and play the media.
The '527 Publication proposes that each peer client buffers the media it has played for a certain period of time, depending on the size of its buffer. The client buffer is divided into three parts: 1) just played, which caches the media the peer has played; 2) ready to play, which stores the stream received and ready to be played; and 3) collecting, which is a space for collecting the stream from multiple parents (see e.g, paragraphs 0038-0041 of the '527 Publication). In the '527 Publication, for a peer y to become a parent of another peer x, its just played buffer must contain the stream data which is being collected by x. The '527 Publication proposes use of DHT, an efficient P2P searching technique, to identify parents for a peer to connect to, see e.g., paragraphs 0043-0046 of the '527 Publication.
The '527 Publication further explains its process as follows in paragraph 0047:                After connecting to several parents, the peer needs to coordinate its parents for streaming non-overlapping parts of the media. The preferred embodiment divides each media [into] W segments with each segment containing 1-second media, and then divides each segment further into M equal-sized blocks. For example, 1-second video of bitrate 450 kbps is divided into 64 blocks, and thus each block is about 900 bytes which fits into one packet. For each segment of media, a bitmap representation is sent to a parent fort [sp: “for”] requesting data blocks from that parent. Each block in the segment is represented by one bit, with the bit set to 1 indicating requesting block. With another 2-byte segment number, all data blocks in the media can be identified uniquely.        
The '527 Publication focuses on video-on-demand content distribution, and does not address live streaming content, for example.
A desire exists for an alternative and/or improved technique for scheduling data requests in a P2P network, particularly for a scheduling technique that is suitable for scheduling peer data requests for live streaming data.